Now that we have the impl_pass_run function as a helper for implementing ComposablePass.run where is the __call__ method actually used in the pass implementation?

This was a suggestion from Seyon. Most usecases just need the Hugr after the pass, so we provide a simple call method.

When we actually need to inspect the result/pass output we can use the other call.

inplace_call and copy_call are the same function here, is that right? Either of them will capture local variable inplace: bool = True specified in the call to run.

Ah ok. I think the one that's going to be used will have the correct semantics, and the callback that isn't going to be used....had better not be, it will not work correctly

Added explicit flag overrides

Ok, so if inplace = True,

• original_dirty == modified, and the transformed Hugr is the input Hugr

whereas if inplace == False,

• original_dirty should always be False
• modified indicates whether the output Hugr == the input
• (probably but not necessarily) the output never is the input. (We might want to allow the latter if modified is False)

modified indicates whether the output Hugr == the input; but (probably, not necessarily) the output never is the input. (We might want to allow the latter if modified is False)

Conditionally aliasing the output is a bug waiting to happen. If we say the output is a copying the object then we should always do that.
Otherwise we may start modifying the result and unintentionally changing the original too.

Sure. Ok, so - if inplace:

• original_dirty == modified
• output Hugr is input Hugr

if not inplace:

• original_dirty == False? (Right? We don't allow it to be partially invalidated or anything)
• (output Hugr is input Hugr) is always False
• modified indicates whether the output Hugr == the input

To me this name feels too "internal". I know it's inside an underscored module but when we stabilize it we may want a better name.

Renamed it to "implement_pass_run".
Not the best either, but hopefully a bit less internal-sounding

Is "dirty" the right word here? The meaning of original_dirty and modified look very similar. I don't actually see the point of the original_dirty flag. Presumably the user either knows or doesn't care whether the pass was called in-place.

Replaced original_dirty with just an inplace flag.
I think it's nice to have a flag assuring you whether the hugr got copied or not, but it's not super important.

Yeah. We also rule out any optimization that wants to destroy the input Hugr in the process of constructing an all-new output Hugr. I mean, ruling that out might be good ;)

Not sure why we include the pass name here?

Mostly for debuggability, otherwise ComposedPass.run would return a List[Any] of arbitrary payloads without much indication of what came from where.

The result may also be serialized, so the original ComposedPass and its list of passes may be lost.

I thought including the pass name was quite a nice solution!

I actually think you can just do:

def run(self, hugr: Hugr, *, inplace: bool = True) -> PassResult:
  pass_result = PassResult(hugr=hugr)
  for pass_ in self.passes:
    new_result = pass_.run(pass_result.hugr, inplace=inplace)
    pass_result = pass_result.then(new_result)
  return pass_result

Because pass_.run always returns a PassResult containing the result hugr; we don't care whether that's the input hugr or a fresh one.

That's already the case, or I'm missing something?